GitLab and GitLab CI

GitLab is a web-based DevOps lifecycle tool that provides Git repository management, issue-tracking, and CI/CD pipeline features using an open-source license. In this section of the lab, you will explore the GitLab repository that contains the Services as Code (SaC) configuration files.

Step 1 - Navigate to GitLab server

Click on the link below to login to GitLab:

• GitLab: https://gitlab.sac-caf-07.svsrtpdmz.cisco.com/CiscoLive/SaC-CAIT-Lab

Step 2 - Enter GitLab Credentials

You will be redirected to a login screen. Enter the provided username and password:

1. Username: user07
2. Password: c1sco123

Step 3 - Accessing Repository contents

The SaC-CAIT-Lab repository is already created and initialized with the necessary files for the lab. Additional configuration files will be added to the repository as we progress through the lab.

1. Locate and open the data directory to view that there are no configuration YAML files present. The SaC solution will take all the available files in the data directory and push the configuration to the ACI fabric. So, All ACI related configuration files need to be placed inside this data directory.






2. Return to the SaC-CAIT-Lab root folder
3. Locate and open .gitlab-ci.yml configuration file to view the Gitlab CI/CD pipeline configuration stages defined for execution.
   
   
   
   
   
4. There are four stages defined for pipeline execution by the .gitlab-ci.yml file. Review the pipeline stages:


1. validate: The validation stage is executed to perform a syntactic and semantic validation of YAML files containing the configurations for the ACI fabric



  

validate:
  stage: validate
  script:
    - set -o pipefail && terraform fmt -check |& tee fmt_output.txt
    - set -o pipefail && iac-validate ./data/ |& tee validate_output.txt
  artifacts:
    paths:
      - fmt_output.txt
      - validate_output.txt
  cache: []
  rules:
    - if: $CI_COMMIT_TAG == null
    

  
  

2. plan: The plan stage is executed to download the required Terraform modules and providers, and generate a plan for the configuration changes that needs to be applied to the ACI fabric



            
          
plan:
  stage: plan
  resource_group: apic
  script:
    - terraform init -input=false
    - terraform plan -out=plan.tfplan -input=false
    - terraform show -no-color plan.tfplan > plan.txt
    - terraform show -json plan.tfplan | jq > plan.json
    - terraform show -json plan.tfplan | jq '([.resource_changes[]?.change.actions?]|flatten)|{"create":(map(select(.=="create"))|length),"update":(map(select(.=="update"))|length),"delete":(map(select(.=="delete"))|length)}' > plan_gitlab.json
  artifacts:
    paths:
      - plan.json
      - plan.txt
      - plan.tfplan
      - plan_gitlab.json
    reports:
      terraform: plan_gitlab.json
  dependencies: []
  needs:
    - validate
  only:
    - merge_requests
    - main
            
            

3. deploy: The deploy stage is executed to push the actual configurations generated with the details from the plan stage to the ACI fabric



            
          
deploy:
  stage: deploy
  resource_group: apic
  script:
    - terraform init -input=false
    - terraform apply -input=false -auto-approve plan.tfplan
  dependencies:
    - plan
  needs:
    - plan
  only:
    - main
            
            

4. test: The test stage is designed to execute the integrated configuration verification test cases as a post-deployment verification method



            
          
test-integration:
  stage: test
  script:
    - set -o pipefail && iac-test -d ./data -d ./defaults.yaml -t ./tests/templates -f ./tests/filters -o ./tests/results/aci |& tee test_output.txt
  artifacts:
    when: always
    paths:
      - tests/results/aci/*.html
      - tests/results/aci/xunit.xml
      - test_output.txt
    reports:
      junit: tests/results/aci/xunit.xml
  dependencies:
    - deploy
  needs:
    - deploy
  only:
    - main
            
            

The integrated test stage test cases are written in Robot Framework and executed against the ACI fabric to verify that the configurations are applied as intended. The integrated test coverage remains at the configuration verification level and does not include operational state or data plane validation. To accomplish this additional necessity to validate the operational state and data plane for the ACI fabric, we will leverage CXTM.

Continue to the next section to configure a tenant on the ACI fabric.